From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0001.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0001.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  


From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0001.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG






From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 


From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti


From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0003.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0002.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0002.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0001.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0001.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment.htm>

From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0004.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0003.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0003.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0002.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0002.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0001.htm>

From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0005.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0004.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0004.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0003.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0003.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0002.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment.htm>

From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0006.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0005.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0005.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0004.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0004.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0003.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0001.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>

From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine

From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx

From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen

From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 


From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0007.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0006.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0006.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0005.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0005.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0005.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0003.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0002.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx

From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx

From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0001.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason

From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx

From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 


From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0008.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0007.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0007.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0006.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0006.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0006.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0004.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0003.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0002.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0009.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0008.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0008.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0007.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0007.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0007.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0005.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0004.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0003.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment.h>

From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0010.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0009.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0009.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0008.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0008.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0008.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0006.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0005.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0004.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0001.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0001.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0001.h>

From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0011.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0010.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0010.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0009.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0009.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0009.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0007.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0006.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0005.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0002.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0002.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0002.h>

From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0012.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0011.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0011.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0010.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0010.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0010.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0008.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0007.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0006.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0003.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0003.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0003.h>

From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0013.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0012.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0012.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0011.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0011.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0011.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0009.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0008.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0007.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0004.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0004.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0004.h>

From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0014.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0013.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0013.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0012.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0012.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0012.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0010.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0009.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0008.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0005.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0005.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0005.h>

From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0015.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0014.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0014.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0013.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0013.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0013.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0011.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0010.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0009.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0006.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0006.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0006.h>

From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0016.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0015.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0015.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0014.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0014.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0014.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0012.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0011.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0010.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0007.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0007.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0007.h>

From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0017.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0016.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0016.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0015.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0015.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0015.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0013.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0012.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0011.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0008.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0008.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0008.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0001.jpg>

From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0018.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0017.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0017.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0016.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0016.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0016.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0014.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0013.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0012.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0010.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0010.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0010.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0002.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0002.jpg>

From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0019.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0018.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0018.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0017.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0017.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0017.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0015.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0014.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0013.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0011.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0011.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0011.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0003.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0003.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0003.jpg>

From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0020.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0019.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0019.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0018.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0018.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0018.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0016.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0015.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0014.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0012.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0012.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0012.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0004.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0004.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0004.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason

From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 


From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0021.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0020.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0020.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0019.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0019.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0019.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0017.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0016.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0015.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0013.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0013.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0013.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0005.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0005.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0005.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0022.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0021.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0021.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0020.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0020.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0020.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0018.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0017.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0016.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0014.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0014.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0014.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0006.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0006.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0006.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0023.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0022.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0022.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0021.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0021.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0021.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0019.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0018.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0017.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0015.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0015.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0015.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0007.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0007.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0007.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0024.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0023.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0023.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0022.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0022.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0022.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0020.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0019.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0018.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0016.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0016.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0016.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0008.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0008.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0008.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0025.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0024.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0024.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0023.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0023.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0023.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0021.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0020.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0019.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0017.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0017.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0017.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0009.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0009.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0009.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0026.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0025.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0025.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0024.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0024.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0024.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0022.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0021.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0020.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0018.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0018.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0018.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0010.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0010.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0010.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0027.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0026.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0026.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0025.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0025.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0025.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0023.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0022.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0021.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0019.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0019.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0019.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0011.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0011.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0011.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0028.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0027.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0027.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0026.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0026.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0026.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0024.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0023.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0022.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0020.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0020.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0020.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0012.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0012.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0012.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0029.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0028.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0028.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0027.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0027.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0027.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0025.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0024.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0023.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0021.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0021.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0021.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0013.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0013.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0013.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0030.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0029.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0029.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0028.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0028.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0028.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0026.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0025.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0024.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0022.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0022.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0022.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0014.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0014.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0014.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0031.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0030.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0030.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0029.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0029.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0029.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0027.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0026.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0025.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0023.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0023.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0023.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0015.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0015.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0015.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0032.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0031.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0031.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0030.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0030.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0030.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0028.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0027.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0026.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0024.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0024.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0024.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0016.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0016.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0016.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0033.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0032.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0032.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0031.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0031.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0031.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0029.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0028.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0027.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0025.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0025.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0025.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0017.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0017.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0017.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0034.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0033.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0033.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0032.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0032.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0032.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0030.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0029.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0028.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0026.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0026.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0026.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0018.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0018.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0018.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0035.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0034.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0034.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0033.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0033.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0033.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0031.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0030.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0029.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0027.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0027.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0027.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0019.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0019.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0019.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0036.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0035.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0035.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0034.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0034.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0034.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0032.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0031.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0030.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0028.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0028.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0028.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0020.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0020.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0020.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0037.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0036.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0036.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0035.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0035.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0035.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0033.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0032.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0031.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0029.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0029.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0029.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0021.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0021.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0021.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0038.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0037.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0037.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0036.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0036.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0036.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0034.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0033.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0032.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0030.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0030.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0030.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0022.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0022.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0022.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0039.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0038.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0038.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0037.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0037.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0037.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0035.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0034.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0033.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0031.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0031.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0031.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0023.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0023.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0023.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0040.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0039.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0039.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0038.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0038.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0038.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0036.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0035.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0034.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0032.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0032.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0032.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0024.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0024.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0024.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0041.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0040.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0040.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0039.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0039.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0039.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0037.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0036.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0035.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0033.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0033.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0033.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0025.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0025.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0025.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0042.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0041.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0041.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0040.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0040.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0040.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0038.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0037.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0036.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0034.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0034.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0034.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0026.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0026.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0026.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0043.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0042.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0042.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0041.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0041.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0041.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0039.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0038.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0037.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0035.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0035.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0035.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0027.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0027.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0027.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0044.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0043.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0043.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0042.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0042.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0042.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0040.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0039.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0038.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0036.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0036.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0036.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0028.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0028.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0028.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0045.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0044.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0044.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0043.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0043.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0043.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0041.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0040.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0039.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0037.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0037.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0037.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0029.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0029.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0029.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0046.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0045.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0045.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0044.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0044.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0044.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0042.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0041.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0040.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0038.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0038.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0038.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0030.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0030.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0030.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0047.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0046.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0046.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0045.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0045.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0045.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0043.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0042.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0041.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0039.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0039.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0039.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0031.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0031.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0031.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0048.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0047.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0047.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0046.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0046.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0046.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0044.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0043.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0042.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0040.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0040.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0040.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0032.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0032.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0032.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0049.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0048.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0048.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0047.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0047.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0047.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0045.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0044.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0043.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0041.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0041.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0041.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0033.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0033.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0033.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0050.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0049.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0049.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0048.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0048.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0048.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0046.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0045.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0044.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0042.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0042.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0042.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0034.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0034.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0034.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0051.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0050.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0050.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0049.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0049.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0049.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0047.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0046.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0045.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0043.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0043.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0043.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0035.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0035.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0035.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0052.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0051.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0051.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0050.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0050.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0050.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0048.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0047.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0046.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0044.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0044.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0044.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0036.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0036.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0036.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0053.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0052.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0052.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0051.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0051.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0051.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0049.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0048.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0047.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0045.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0045.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0045.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0037.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0037.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0037.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0054.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0053.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0053.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0052.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0052.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0052.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0050.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0049.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0048.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0046.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0046.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0046.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0038.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0038.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0038.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0055.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0054.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0054.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0053.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0053.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0053.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0051.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0050.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0049.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0047.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0047.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0047.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0039.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0039.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0039.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0056.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0055.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0055.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0054.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0054.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0054.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0052.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0051.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0050.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0048.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0048.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0048.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0040.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0040.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0040.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0057.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0056.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0056.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0055.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0055.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0055.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0053.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0052.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0051.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0049.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0049.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0049.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0041.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0041.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0041.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0058.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0057.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0057.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0056.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0056.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0056.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0054.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0053.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0052.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0050.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0050.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0050.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0042.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0042.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0042.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0059.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0058.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0058.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0057.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0057.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0057.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0055.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0054.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0053.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0051.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0051.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0051.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0043.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0043.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0043.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0060.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0059.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0059.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0058.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0058.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0058.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0056.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0055.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0054.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0052.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0052.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0052.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0044.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0044.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0044.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0061.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0060.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0060.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0059.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0059.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0059.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0057.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0056.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0055.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0053.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0053.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0053.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0045.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0045.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0045.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0062.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0061.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0061.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0060.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0060.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0060.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0058.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0057.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0056.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0054.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0054.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0054.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0046.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0046.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0046.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0063.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0062.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0062.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0061.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0061.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0061.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0059.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0058.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0057.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0055.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0055.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0055.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0047.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0047.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0047.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0064.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0063.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0063.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0062.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0062.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0062.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0060.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0059.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0058.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0056.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0056.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0056.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0048.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0048.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0048.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0065.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0064.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0064.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0063.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0063.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0063.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0061.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0060.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0059.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0057.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0057.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0057.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0049.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0049.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0049.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0066.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0065.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0065.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0064.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0064.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0064.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0062.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0061.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0060.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0058.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0058.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0058.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0050.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0050.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0050.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0067.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0066.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0066.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0065.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0065.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0065.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0063.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0062.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0061.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0059.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0059.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0059.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0051.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0051.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0051.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0068.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0067.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0067.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0066.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0066.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0066.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0064.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0063.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0062.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0060.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0060.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0060.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0052.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0052.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0052.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0069.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0068.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0068.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0067.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0067.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0067.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0065.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0064.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0063.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0061.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0061.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0061.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0053.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0053.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0053.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0070.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0069.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0069.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0068.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0068.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0068.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0066.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0065.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0064.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0062.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0062.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0062.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0054.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0054.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0054.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0071.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0070.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0070.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0069.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0069.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0069.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0067.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0066.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0065.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0063.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0063.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0063.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0055.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0055.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0055.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0072.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0071.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0071.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0070.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0070.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0070.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0068.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0067.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0066.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0064.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0064.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0064.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0056.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0056.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0056.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0073.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0072.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0072.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0071.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0071.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0071.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0069.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0068.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0067.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0065.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0065.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0065.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0057.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0057.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0057.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0074.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0073.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0073.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0072.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0072.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0072.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0070.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0069.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0068.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0066.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0066.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0066.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0058.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0058.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0058.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0075.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0074.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0074.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0073.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0073.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0073.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0071.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0070.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0069.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0067.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0067.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0067.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0059.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0059.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0059.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0076.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0075.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0075.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0074.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0074.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0074.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0072.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0071.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0070.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0068.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0068.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0068.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0060.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0060.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0060.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0077.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0076.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0076.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0075.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0075.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0075.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0073.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0072.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0071.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0069.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0069.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0069.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0061.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0061.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0061.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0078.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0077.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0077.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0076.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0076.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0076.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0074.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0073.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF568A@DE08EV1001.global.ds.honeywell.com>

Thanks Mariusz. I will upgrade to 2.2 pre and  give it a try.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Pawan.Kharbanda at dot.state.co.us  Tue Dec  7 13:17:25 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 7 Dec 2010 13:17:25 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A51675E81E@HQEXCHANGECMS.dot.state.co.us>

Hi --
  I think i got closer to where the problem is ... but still don't have an answer. I need to know why RXTX is resetting INPUT Modes. I am using "ditty-rp" (same as stty) to set Input modes. But when i run a program with RXTX, all the changes are reset to original

ditty-rp cooked /dev/ttyk14
-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

After I run my program to do a test on port /dev/ttyk14 (9600-8-1-N) all the Input Params are reset.

-bash-3.2$ ditty-rp -a /dev/ttyk14
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 100 bufsize 100 edelay 250
-forcedcd -altpin -fastbaud (9600) -printer -rtstoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD-  DSR+  RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echopr
t
-echoctl -echoke

It seems like RXTX is resetting them. Can somebody answer this?

Thanks again
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan
Sent: Friday, December 03, 2010 11:22 AM
To: M.Dec-GM; rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101207/8a2c38cc/attachment-0072.htm>

From jmsachs at gmail.com  Tue Dec  7 13:39:40 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 7 Dec 2010 15:39:40 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 6
In-Reply-To: <mailman.4155.1291750651.2879.rxtx@qbang.org>
References: <mailman.4155.1291750651.2879.rxtx@qbang.org>
Message-ID: <AANLkTinNZ3q2SxPu=0BFE1qUfMKDG4KaT41QkaeY3-0e@mail.gmail.com>

> Message: 2
> Date: Tue, 7 Dec 2010 07:00:14 +0100
> From: "M.Dec-GM" <mariusz.dec at gmail.com>
> To: <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port
> Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35 at mdam3>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> ? ? ? ?reply-type=original
>
> Hi,
> Me and friends here have several times discussed about closing port in RXTX
> and recovering connection.
> I have published several times example which shows way to recovery
> connection.
> It works with 2.2 pre and have helped several times.
> Look for this and try, especially in simple back-loop connection.
> It should show proper (or not) work of the drivers.
> Generally - change RXTX to 2.2 pre.
> Regards
> Mariusz

Please note that Mariusz's solution -- which essentially amounts to
careful supervision of the RXTX input/output streams, e.g. closing the
streams when a disconnect is detected, and no further reading/writing
to the streams once a disconnect is detected -- may help but is not
guaranteed to work, and is likely to fail at high data rates.

There is a small but finite probability of the serial port
disappearing (=disconnection for USB) while the RXTX library itself is
in the middle of a write() call, and you can get a JVM crash this way.

About a month ago I had developed a test harness for investigating
this issue, to see under which conditions but had to abandon work on
it due to an extended vacation + other time commitments (e.g. my real
job). If I have time within the next few weeks I'll post my code.

I would just request that if people are interested in solving the RXTX
USB disconnect issue, that you put your efforts towards fixing the
problem (preventing JVM crashes + printf() calls, and instead passing
exceptions to Java) and producing precompiled binaries for the major
platforms.

--Jason


From Wei.Shen at Honeywell.com  Tue Dec  7 14:51:47 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 16:51:47 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>

Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


			try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				try {
	
link.getPort().getInputStream().close();
	
link.getPort().getOutputStream().close();
				} catch (IOException e2) {
				}
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				try {
					Thread.sleep(2000);         //
add some delay
					String portName =
link.getPortName();
					link = new CommunicationLink(
							(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
					System.err.println("port
open="+portName);
				} catch (Exception e1) {
					e1.printStackTrace();
					log.error(e1);
					if (link != null) {
						link.getPort().close();
					}
				}
			}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From mariusz.dec at gmail.com  Tue Dec  7 15:24:22 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 23:24:22 +0100
Subject: [Rxtx] rxtx how to recover from a disconnect
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com><83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
	<74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
	<83B3B1411349194D9D05821CEF48E78C01CF5A51@DE08EV1001.global.ds.honeywell.com>
Message-ID: <FD364276F9E74566B3DCB6A0029E68CB@mdam3>

Hi Shen,
ANY SPECIFIC DELAY? -- NO !!!!!!!

There is no delay as an important thing.
Delays are in example application to better show processes.

The keys are:
- Port configuration
- Exception services
- waiting for port close until native process is busy - Close Mutex or 
something like that.

First example from Nov '2009 isn't perfect.
Better solutions were this year - Semptember?
I don't remember.
Look for my posts in opposite direction than dates - back from now.
I am extremelly busy now and I haven;'t time to analyse your work, sorry.
Start from EXACT environment and code which I have mentioned and probably 
you will find a solution.
Regards
Mariusz




----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
To: "M.Dec-GM" <mariusz.dec at gmail.com>; <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 10:51 PM
Subject: RE: [Rxtx] rxtx how to recover from a disconnect


Hi Mariusz,

Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
closing the port. I think your suggestion was to add some delay after
closing the port. Please correct me if I am wrong. I tried it. Windows
thrown error message when I unplug the USB cable. It seems the
rxtxSerial.dll caused the application to crash. I paste the recovery
portion of the code below. I am using Windows XP SP3 32 bit. Any
comments?


try {
sendMessage(destination, payLoad);
receivedMessage = receiveMessage();
return receivedMessage;
} catch (Exception e) {
e.printStackTrace();
log.error(e);
try {

link.getPort().getInputStream().close();

link.getPort().getOutputStream().close();
} catch (IOException e2) {
}
link.getPort().close();
System.err.println("port
closed:"+link.getPortName());
try {
Thread.sleep(2000);         //
add some delay
String portName =
link.getPortName();
link = new CommunicationLink(
(SerialPort)
CommPortIdentifier.getPortIdentifier(portName).open("Comm", 2000),
portName); // try to reopen the same port for recovery it crashed the
//application
System.err.println("port
open="+portName);
} catch (Exception e1) {
e1.printStackTrace();
log.error(e1);
if (link != null) {
link.getPort().close();
}
}
}


-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of M.Dec-GM
Sent: December 6, 2010 11:00 PM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx hang on RIM virtual serial port

Hi,
Me and friends here have several times discussed about closing port in
RXTX
and recovering connection.
I have published several times example which shows way to recovery
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried
to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From tjarvi at qbang.org  Thu Dec  9 17:49:34 2010
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 9 Dec 2010 17:49:34 -0700 (MST)
Subject: [Rxtx] bug in 'SerialImp' module for rxtx library (fwd)
Message-ID: <alpine.LFD.2.00.1012091749240.9101@rxtx.qbang.org>



---------- Forwarded message ----------
Date: Mon, 06 Dec 2010 22:35:04 -0800
From: bobf <bobf at mrp3.com>
To: tjarvi at qbang.org
Subject: bug in 'SerialImp' module for rxtx library

Under FreeBSD 7.3 (amd64), using the 2.1.7 version of the rxtx source, 
applications that attempt to read from a COM port always crash.

the cause of the crash is actually very simple:  use of GetIntField instead of 
GetObjectField for access to a java variable via a pointer.

On a related note, FreeBSD uses the Diablo JDK.

the attached 3 patch files appear to correct this problem.  Please incorporate 
a similar change into the next release of rxtx.  From what I recall, I 
researched a similar problem once before and the use of 'GetIntField' in this 
manner is actually deprecated.  Unless people are using ancient JDKs to build 
the library i would suggest using GetObjectField and also doing the 
de-reference prior to returning from the function that accesses the variable by 
reference.

FYI I am using the Arduino IDE which makes use of the rxtx library, and it's 
now working more or less as I would expect it to.

bug report submitted to FreeBSD ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152882

(suggested patch files attached)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.c
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0070.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.cpp
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0070.el>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-SerialImp.h
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101209/e0de2ac5/attachment-0070.h>

From Thomas.Damgaard at polycom.com  Fri Dec 17 12:44:38 2010
From: Thomas.Damgaard at polycom.com (Damgaard, Thomas)
Date: Fri, 17 Dec 2010 19:44:38 +0000
Subject: [Rxtx] java.lang.NoClassDefFoundError: gnu/io/PortInUseException
Message-ID: <651D981E4B29F74ABD63CE74C2E4788E2F32E56E@SLOMAILPRD01.polycom.com>

Hi,

I load the native and Java lib using the jnlp script for my applet:
    <resources>
        <jar href="RXTXcomm.jar" />
    </resources>
    <resources os="Linux">
        <nativelib href="rxtx-native-linux.jar"/>
    </resources>
    <resources os="Windows">
        <nativelib href="rxtx-native-windows32.jar"/>
    </resources>

This works fine on Windows and Linux when I'm using Sun's Java. However if I use the standard Java preinstall on Fedora, OpenJDK, I get the following error:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Server VM (build 19.0-b09, mixed mode)
Exception in thread "Applet" java.lang.NoClassDefFoundError: gnu/io/PortInUseException
                             at java.lang.Class.getDeclaredConstructors0(Native Method)
                             at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
                             at java.lang.Class.getConstructor0(Class.java:2716)
                             at java.lang.Class.newInstance0(Class.java:343)
                             at java.lang.Class.newInstance(Class.java:325)
                             at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:588)
                             at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
                             at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
                             at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
                             at sun.applet.AppletPanel.run(AppletPanel.java:380)
                             at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
                             at sun.applet.AppletPanel.run(AppletPanel.java:430)
                             at java.lang.Thread.run(Thread.java:636)

The only difference is what Java I use.
I'm using RXTX version 2.2pre2.

I would be really helpful if our customers wouldn't have to install Sun's Java.


Best regards,
Thomas Fogh Damgaard, R&D B.Sc.E.E., Polycom (Denmark) ApS, KIRK Business Unit

[cid:image001.gif at 01CB9E27.02480AA0]<http://www.polycom.com/>
[cid:image002.jpg at 01CB9E27.02480AA0]Please consider your environmental responsibility before printing this e-mail

This communication (including any attachments) may contain privileged or confidential information of Polycom and is intended for a specific individual.  If you are not the intended recipient, you should delete this communication, including any attachments without reading or saving them in any manner, and you are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0062.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2257 bytes
Desc: image001.gif
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0062.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 851 bytes
Desc: image002.jpg
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101217/82630510/attachment-0062.jpg>

From jmsachs at gmail.com  Tue Dec 21 06:10:57 2010
From: jmsachs at gmail.com (Jason Sachs)
Date: Tue, 21 Dec 2010 08:10:57 -0500
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
In-Reply-To: <mailman.6069.1292612602.2879.rxtx@qbang.org>
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
Message-ID: <AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>

> Date: Tue, 7 Dec 2010 16:51:47 -0500
> From: "Shen, Wei (AB21)" <Wei.Shen at Honeywell.com>
> To: "M.Dec-GM" <mariusz.dec at gmail.com>, <rxtx at qbang.org>
> Subject: Re: [Rxtx] rxtx how to recover from a disconnect
> Message-ID:
> ? ? ? ?<83B3B1411349194D9D05821CEF48E78C01CF5A51 at DE08EV1001.global.ds.honeywell.com>
>
> Content-Type: text/plain; ? ? ? charset="us-ascii"
>
> Hi Mariusz,
>
> Thanks for your reply. I upgraded to 2.2 pre. I did find your posting on
> closing the port. I think your suggestion was to add some delay after
> closing the port. Please correct me if I am wrong. I tried it. Windows
> thrown error message when I unplug the USB cable. It seems the
> rxtxSerial.dll caused the application to crash. I paste the recovery
> portion of the code below. I am using Windows XP SP3 32 bit. Any
> comments?

Wei: What data rates are you using? Both baud rate + approx # of bits
per second sending / receiving are useful #'s -- note that they are
not the same; you could be using a 57600baud connection and only
sending 1 byte per second and receiving 10 bytes per second, or you
could be using 57600baud and the maximum throughput of 5760bytes per
second in both directions (1 byte = 8 data bits + 1 start bit + 1 stop
bit = 10 baud bits).

If your data rates are low, you may be able to use Mariusz's
workaround correctly. Otherwise, I believe the USB disconnect problem
in rxtx does not have a valid workaround for high data rates (not sure
what the threshold is, but if you're sending thousands of bytes per
second, it will probably crash no matter what).


Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved.

--Jason


From mariusz.dec at gmail.com  Tue Dec 21 07:21:25 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 21 Dec 2010 15:21:25 +0100
Subject: [Rxtx] Rxtx Digest, Vol 40, Issue 7
References: <mailman.6069.1292612602.2879.rxtx@qbang.org>
	<AANLkTinn2FGZqGuWJKXwzWFi-oAu+wGK3h1U8NJdZiOf@mail.gmail.com>
Message-ID: <509BDB37E87D4DDEB1761A94844CA78B@mdam3>

Hi All,
Hi Jason,

You have written:

" Mariusz: If you are going to be the main person who suggests
workarounds for serial port disconnects, please start adding a warning
that there are situations for which the workarounds you describe do
not help. If you won't, I will. I don't mean to make you sound like a
bad person, and I think you've done a lot of work on this mailing list
to help, but it's not fair to suggest to people that they just need to
do what you say and their problem will likely be solved."

Yes, you are right, but please note that I have started from impossible 
mission: port close() more than one year ago.
After weeks of work I have found good way to be sure that port may be 
closed.
In the next step I have found Java workaround for USB disconnection.

I have written somewhere earlier all my conditions - many short packets with 
speed of 57600.

But I didn't need big packets, sorry.

Few weeks ago somebody has found buffer limitation inside C part of RXTX.
I hope that both solutions together may are enough.

And I have written many times that this solution may not work in some 
situations, because of drivers, chip configurtions etc.
So - maybe I am "bad boy". maybe not  :).
I have noticed many times that my solution helps in MANY cases.
I haven't NEVER write that this is solution very good for ALL cases.
BTW: buffer limitations and USB disconection prevention haven't connection - 
there are separate problems I think - yes or not?

Regards
BAD BOY Mariusz :))))

--Jason
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx 



From johnco3 at gmail.com  Wed Dec  1 16:58:48 2010
From: johnco3 at gmail.com (John Coffey)
Date: Wed, 1 Dec 2010 18:58:48 -0500
Subject: [Rxtx] Windows 7 32-bit issues
In-Reply-To: <001001cb8a55$3f819020$be84b060$@de>
References: <001001cb8a55$3f819020$be84b060$@de>
Message-ID: <AANLkTikqt+uqhj338LOPYO_AtTtPnGSSnysxS-Bgxvwk@mail.gmail.com>

I encountered a similar problem like the one you describe - the problem has
do with the way the termios.c opens the port using a default buffer size
that is too small.  I needed an 8K buffer for my application and I ended up
having to make the following dirty hack in the termios.c code which I've
been keeping to myself as its not really the right thing to do as a general
purpose solution - I would find that serial IO would come to a blinding halt
if my buffer size exceeded 4k or so (not sure of the exact number but that
rings a bell).

    // @JC HACK//  if( !SetupComm( port->hComm, 2048, 1024 ) )    if(
!SetupComm( port->hComm, 8200, 8200 ) )    {        YACK();
return -1;    }

Unfortunately the mechanism of specifying the input and output bufffer size
via gnu.io.CommPort end up as native no-ops by the time they end up at the
native driver layer - I wish someone would fix this sometime.

In CommPort.java the interface to specify the sizes for the input and output
buffers for the comm port exists but it ends up being ignored....

John Coffey

package gnu.io;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public abstract class CommPort {
. . .

    public abstract void setInputBufferSize(int i);

    public abstract int getInputBufferSize();

    public abstract void setOutputBufferSize(int i);

    public abstract int getOutputBufferSize();
. . .
}



On Mon, Nov 22, 2010 at 9:55 AM, Emanuel <eb at inotec-feg.de> wrote:

> I?m using rxtx on windows xp in my application and it is working.
>
> On Windows 7 (32 bit) the application basically works but hangs upon
> receiving larger ?packets?.
>
> In both cases a usb-uart adapter is used.
>
> Problem persists until unplugging the adapter.
>
> Rxtx Version:  2.1-7-bins-r2
>
> No Exception is thrown and no indication is showing up helping identifying
> the problem source.
>
> Are there any known issues with rxtx and Windows 7 possibly producing such
> behavior?
>
>
>
> Thanks in advance
>
> Emanuel
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101201/19fedb3d/attachment-0079.htm>

From Pawan.Kharbanda at dot.state.co.us  Thu Dec  2 14:13:35 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Thu, 2 Dec 2010 14:13:35 -0700
Subject: [Rxtx] Missing Data
Message-ID: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
        boolean debug = log.isDebugEnabled() ;
        boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
                in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                        break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
                if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101202/e660d625/attachment-0078.htm>

From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:34:35 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:34:35 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>

Looking at your data I see that the missing byte comes right after 0C which
is the CR (Carriage Return) ASCII code and this is suspicious, as some
serial drivers eat/convert CR/LF in various ways depending on how they are
initialized. This 

This was discussed on this list just a few weeks ago. At that time it turned
out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
maintainer) informed that the port is properly initialized in RXTX code, so
this should not be an issue in RXTX.

Just my 2 snt worth but I would investigate this hypothesis / hunch first.

An other hunch is that the missing byte is FF which is on the serial line
basically just a single start bit (0) so it is more likely to get lost if
you have issues in the electronic. Not very likely but I've seen weirder
things.

br Kusti


> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
> Reply-To: <rxtx at qbang.org>
> Date: Thu, 2 Dec 2010 23:13:35 +0200
> To: <rxtx at qbang.org>
> Conversation: Missing Data
> Subject: [Rxtx] Missing Data
> 
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02
> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02
> 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02
> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03
> 00 01 25 88 0a 55 32 36 fd e7 7e
>  



From mariusz.dec at gmail.com  Fri Dec  3 00:40:38 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:40:38 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <668FF81AA26E46599917BD54D5675280@mdam3>

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: rxtx at qbang.org 
  Sent: Thursday, December 02, 2010 10:13 PM
  Subject: [Rxtx] Missing Data


  Hi --
     We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

  Thanks in advance
  Pawan


  Correct Packet 64 bytes (thru split)
  7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
  Incorrect Packet 63 bytes
  7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

  Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
  2010 x86_64 x86_64 x86_64 GNU/Linux

  java version "1.6.0_17"
  Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

  Jar version = RXTX-2.2
  native lib Version = RXTX-2.2pre2

  Red Hat Enterprise Linux Server release 5.5 (Tikanga)

  HERE is a piece of code that is doing communication

  protected byte[] receive(
              int timeout, int maxBytes)
              throws ReceiveFailedException {
           boolean debug = log.isDebugEnabled() ;
           boolean trace = log.isTraceEnabled();
          InputStream in = null;
          if (this.isClosed())
              throw new ReceiveFailedException("Port '"
                      + this.getConnectionName() + "' has already been closed");
          byte[] retBuffer = new byte[0];
          SerialPort tmpSerialPort = this.getSerialPort();
          tmpSerialPort.setRTS(true);
          byte[] recvBuffer = new byte[maxBytes];
          String portName = tmpSerialPort.getName();
          BufferedInputStream bis = null;
          try {
           in = tmpSerialPort.getInputStream();
              bis = new BufferedInputStream(in);

              long startRecv = System.currentTimeMillis() ;
              long now = startRecv;
              int numRead = 0;
              int totalBytesRead = 0;

              // keep reading from the input stream unitl maxbytes are recieved or 
              // timout (maxRead Duration) is reached
              while (((now - startRecv) < timeout)
                      && (totalBytesRead < maxBytes)) {
                  numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                  if (numRead > 0) {
                      totalBytesRead += numRead;
                  }
                  now = System.currentTimeMillis() ;
                  // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                  if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                   break;
                  }
              }
              tmpSerialPort.setRTS(false);
              if (debug)
                      log.debug("["
                                                  + tmpSerialPort.getName()
                                                  + "] : Received " + totalBytesRead + " bytes.");
              //Copy what we have to the return buffer
              if (trace)
                                  log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

              retBuffer = new byte[totalBytesRead];
              System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

          } catch (Exception e) {
              String errMsg = "Port '" + portName
                      + "': Failure while reading data - " + e.toString();
              if (debug)
                  log.debug(errMsg);
              throw new ReceiveFailedException(errMsg);
          } finally{
           if (bis!=null)
                                  try {
                                          bis.close();
                                  } catch (IOException e) {
                                          
                                  }
          }
          // update timestamp
          setLastTimeReceived(System.currentTimeMillis());

          return retBuffer;
      }



------------------------------------------------------------------------------


  _______________________________________________
  Rxtx mailing list
  Rxtx at qbang.org
  http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/f4c198bd/attachment-0078.htm>

From Bob_Jacobsen at lbl.gov  Fri Dec  3 00:41:30 2010
From: Bob_Jacobsen at lbl.gov (Bob Jacobsen)
Date: Thu, 2 Dec 2010 23:41:30 -0800
Subject: [Rxtx] Missing Data
In-Reply-To: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <A3426634-5FD2-467A-ADB4-77F8B0DD2958@lbl.gov>

Two things immediately present, though I'm not sure either is the problem.

1) You're creating a BufferedInputStream to look at the SerialPort's InputStream, using it for a while, then discarding it.  There's nothing in RXTX or the stream code that guarantees that the BufferedInputStream won't have read ahead from the underlying InputStream after the end of the message, in which case you'll lose that input data.  Is there something the protocol that really guarantees that?  If not, you might want to switch to a structure that creates a single BufferedInputStream early on, and just uses the same one over and over.

2) The code sits in a tight loop calling read(,,0), i.e.repeatedly invoking a read with a max length of zero, while the message comes in.  If the program is running behind on the input stream (e.g. the data is already inside the Java code, just waiting to get to you) this might be OK (but see above about buffering), but if you're waiting for the data to arrive this is a very CPU-intensive way to do that.  If you've got multiple copies of this running at once, which you seemed to imply you do, it's not clear how these will share CPU and get the timeouts to work right.  Unless you've got an incredibly high baud rate, you might want to try adding a 1msec delay to the loop if it finds no data.

Bob

On Dec 2, 2010, at 1:13 PM, Kharbanda, Pawan wrote:

> Hi --
>    We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server IIhttp://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.
>  
> Thanks in advance
> Pawan
>  
>  
> Correct Packet 64 bytes (thru split)
> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
> Incorrect Packet 63 bytes
> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e
>  
> Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>  
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
> Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
>  
> Jar version = RXTX-2.2
> native lib Version = RXTX-2.2pre2
>  
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>  
> HERE is a piece of code that is doing communication
>  
> protected byte[] receive(
>             int timeout, int maxBytes)
>             throws ReceiveFailedException {
>          boolean debug = log.isDebugEnabled() ;
>          boolean trace = log.isTraceEnabled();
>         InputStream in = null;
>         if (this.isClosed())
>             throw new ReceiveFailedException("Port '"
>                     + this.getConnectionName() + "' has already been closed");
>         byte[] retBuffer = new byte[0];
>         SerialPort tmpSerialPort = this.getSerialPort();
>         tmpSerialPort.setRTS(true);
>         byte[] recvBuffer = new byte[maxBytes];
>         String portName = tmpSerialPort.getName();
>         BufferedInputStream bis = null;
>         try {
>          in = tmpSerialPort.getInputStream();
>             bis = new BufferedInputStream(in);
>  
>             long startRecv = System.currentTimeMillis() ;
>             long now = startRecv;
>             int numRead = 0;
>             int totalBytesRead = 0;
>  
>             // keep reading from the input stream unitl maxbytes are recieved or
>             // timout (maxRead Duration) is reached
>             while (((now - startRecv) < timeout)
>                     && (totalBytesRead < maxBytes)) {
>                 numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
>                 if (numRead > 0) {
>                     totalBytesRead += numRead;
>                 }
>                 now = System.currentTimeMillis() ;
>                 // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
>                 if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
>                  break;
>                 }
>             }
>             tmpSerialPort.setRTS(false);
>             if (debug)
>                     log.debug("["
>                                                 + tmpSerialPort.getName()
>                                                 + "] : Received " + totalBytesRead + " bytes.");
>             //Copy what we have to the return buffer
>             if (trace)
>                                 log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");
>  
>             retBuffer = new byte[totalBytesRead];
>             System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);
>  
>         } catch (Exception e) {
>             String errMsg = "Port '" + portName
>                     + "': Failure while reading data - " + e.toString();
>             if (debug)
>                 log.debug(errMsg);
>             throw new ReceiveFailedException(errMsg);
>         } finally{
>          if (bis!=null)
>                                 try {
>                                         bis.close();
>                                 } catch (IOException e) {
>                                        
>                                 }
>         }
>         // update timestamp
>         setLastTimeReceived(System.currentTimeMillis());
>  
>         return retBuffer;
>     }
>  
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

--
Bob Jacobsen, LBNL
Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG







From mariusz.dec at gmail.com  Fri Dec  3 00:43:58 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 08:43:58 +0100
Subject: [Rxtx] Missing Data
References: <C91E6A2B.179BE%kustaa.nyholm@planmeca.com>
Message-ID: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>

Hi Kusta,
little mistake - 0x0C is Form Feed, CR is 0x0D. :)
Regards
Mariusz

----- Original Message ----- 
From: "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com>
To: <rxtx at qbang.org>
Sent: Friday, December 03, 2010 8:34 AM
Subject: Re: [Rxtx] Missing Data


> Looking at your data I see that the missing byte comes right after 0C 
> which
> is the CR (Carriage Return) ASCII code and this is suspicious, as some
> serial drivers eat/convert CR/LF in various ways depending on how they are
> initialized. This
>
> This was discussed on this list just a few weeks ago. At that time it 
> turned
> out to be a bug in the users code (not RXTX) and IIRC Trent (RXTX
> maintainer) informed that the port is properly initialized in RXTX code, 
> so
> this should not be an issue in RXTX.
>
> Just my 2 snt worth but I would investigate this hypothesis / hunch first.
>
> An other hunch is that the missing byte is FF which is on the serial line
> basically just a single start bit (0) so it is more likely to get lost if
> you have issues in the electronic. Not very likely but I've seen weirder
> things.
>
> br Kusti
>
>
>> From: "Kharbanda, Pawan" <Pawan.Kharbanda at dot.state.co.us>
>> Reply-To: <rxtx at qbang.org>
>> Date: Thu, 2 Dec 2010 23:13:35 +0200
>> To: <rxtx at qbang.org>
>> Conversation: Missing Data
>> Subject: [Rxtx] Missing Data
>>
>> 7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 
>> 00 02
>> 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF 
>> FF 02
>> 03 00 01 25 88 0A 55 32 36 FD E7 7E
>> Incorrect Packet 63 bytes
>> 7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 
>> 00 02
>> 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 
>> 02 03
>> 00 01 25 88 0a 55 32 36 fd e7 7e
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Kustaa.Nyholm at planmeca.com  Fri Dec  3 00:54:34 2010
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Fri, 3 Dec 2010 09:54:34 +0200
Subject: [Rxtx] Missing Data
In-Reply-To: <A4F34C15D2E44423AB62E52E63228CDA@mdam3>
Message-ID: <C91E6EDA.179C9%kustaa.nyholm@planmeca.com>


> 
> Hi Kusta,
> little mistake - 0x0C is Form Feed, CR is 0x0D. :)
> Regards
> Mariusz
> 
Tshah, my bad, thanks for spotting it, please disregard then this
hypothesis.

br Kusti



From Pawan.Kharbanda at dot.state.co.us  Fri Dec  3 11:22:22 2010
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 3 Dec 2010 11:22:22 -0700
Subject: [Rxtx] Missing Data
In-Reply-To: <668FF81AA26E46599917BD54D5675280@mdam3>
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
Message-ID: <D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>

Mariusz --
   I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems.

Regards
Pawan

________________________________
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
Sent: Friday, December 03, 2010 12:41 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] Missing Data

Hi all,
interesting...
You are loosing 50th or 51th byte.
If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
Regards
Mariusz

----- Original Message -----
From: Kharbanda, Pawan<mailto:Pawan.Kharbanda at dot.state.co.us>
To: rxtx at qbang.org<mailto:rxtx at qbang.org>
Sent: Thursday, December 02, 2010 10:13 PM
Subject: [Rxtx] Missing Data

Hi --
   We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this.

Thanks in advance
Pawan


Correct Packet 64 bytes (thru split)
7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E
Incorrect Packet 63 bytes
7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

HERE is a piece of code that is doing communication

protected byte[] receive(
            int timeout, int maxBytes)
            throws ReceiveFailedException {
         boolean debug = log.isDebugEnabled() ;
         boolean trace = log.isTraceEnabled();
        InputStream in = null;
        if (this.isClosed())
            throw new ReceiveFailedException("Port '"
                    + this.getConnectionName() + "' has already been closed");
        byte[] retBuffer = new byte[0];
        SerialPort tmpSerialPort = this.getSerialPort();
        tmpSerialPort.setRTS(true);
        byte[] recvBuffer = new byte[maxBytes];
        String portName = tmpSerialPort.getName();
        BufferedInputStream bis = null;
        try {
         in = tmpSerialPort.getInputStream();
            bis = new BufferedInputStream(in);

            long startRecv = System.currentTimeMillis() ;
            long now = startRecv;
            int numRead = 0;
            int totalBytesRead = 0;

            // keep reading from the input stream unitl maxbytes are recieved or
            // timout (maxRead Duration) is reached
            while (((now - startRecv) < timeout)
                    && (totalBytesRead < maxBytes)) {
                numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                if (numRead > 0) {
                    totalBytesRead += numRead;
                }
                now = System.currentTimeMillis() ;
                // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                 break;
                }
            }
            tmpSerialPort.setRTS(false);
            if (debug)
                    log.debug("["
                                                + tmpSerialPort.getName()
                                                + "] : Received " + totalBytesRead + " bytes.");
            //Copy what we have to the return buffer
            if (trace)
                                log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

            retBuffer = new byte[totalBytesRead];
            System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

        } catch (Exception e) {
            String errMsg = "Port '" + portName
                    + "': Failure while reading data - " + e.toString();
            if (debug)
                log.debug(errMsg);
            throw new ReceiveFailedException(errMsg);
        } finally{
         if (bis!=null)
                                try {
                                        bis.close();
                                } catch (IOException e) {

                                }
        }
        // update timestamp
        setLastTimeReceived(System.currentTimeMillis());

        return retBuffer;
    }


________________________________

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/6285cb28/attachment-0077.htm>

From mariusz.dec at gmail.com  Fri Dec  3 11:32:16 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Fri, 3 Dec 2010 19:32:16 +0100
Subject: [Rxtx] Missing Data
References: <D651CC70E21B8645B81A0D2788908D87A515711170@HQEXCHANGECMS.dot.state.co.us>
	<668FF81AA26E46599917BD54D5675280@mdam3>
	<D651CC70E21B8645B81A0D2788908D87A5157114FD@HQEXCHANGECMS.dot.state.co.us>
Message-ID: <1B33DCE262D14D489898C4E765325BEB@mdam3>

Hi Pawan,
no USB - ok, but please note that there is "additional" device in the chain. 
Each device has a micro, micro has buffers for data, software is written by peoples and always may have errors :).
Anyway - without jokes - try to test chain using my idea. I hope it shows more - where to look for errors.
Regards
Mariusz

  ----- Original Message ----- 
  From: Kharbanda, Pawan 
  To: M.Dec-GM ; rxtx at qbang.org 
  Sent: Friday, December 03, 2010 7:22 PM
  Subject: RE: [Rxtx] Missing Data


  Mariusz --
     I am not using USB at all. Digi boxes are accessed over IP thru Real port and are connected thru Serial cable directly to Modems. 

  Regards
  Pawan



------------------------------------------------------------------------------
  From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of M.Dec-GM
  Sent: Friday, December 03, 2010 12:41 AM
  To: rxtx at qbang.org
  Subject: Re: [Rxtx] Missing Data


  Hi all,
  interesting...
  You are loosing 50th or 51th byte.
  If you are using USB-RS dongle it may be problem with internal buffer, but 50 and 51 - this is mysterious.
  Maybe value - 0xFF - this is "plain" electrical signal except start and stop (frame error?).
  Try to send 48, 49, 50, 51 bytes packets without FF (i.e 0xAA, 0x55 on this positions) and check what will happen.
  Regards
  Mariusz

    ----- Original Message ----- 
    From: Kharbanda, Pawan 
    To: rxtx at qbang.org 
    Sent: Thursday, December 02, 2010 10:13 PM
    Subject: [Rxtx] Missing Data


    Hi --
       We have a Production setup on Redhat linux servers with lots of devices doing Serial Modem communication using RXTX pre 2.2 installed. For serial we communicate thru Digi Serial Servers (Port Server II http://www.digi.com/products/serialservers/portserverii.jsp#overview ) which are directly connected to a Modem Bank. Recently we noticed that some of the packets that we are exchanging are missing some data. So we decided to put a Serial Split between Modem and Digi box what we found that a 64 byte packet is received at Modem but on the application side it is only reciving 63 bytes. What is interesting is that data is missing between start and end of the packet and it is getting lost at the same location every time. Is there something in RXTX that I can do to troubleshoot this? Or if somebody can help me understand why I am getting this behavior? Is there any bug in RXTX that might be causing this. 

    Thanks in advance
    Pawan


    Correct Packet 64 bytes (thru split)
    7E 89 13 C1 30 37 02 01 00 04 06 70 75 62 6C 69 63 A2 2A 02 01 00 02 01 00 02 01 00 30 1F 30 1D 06 0D 2B 06 01 04 01 89 36 04 02 03 06 03 00 04 0C FF FF 02 03 00 01 25 88 0A 55 32 36 FD E7 7E 
    Incorrect Packet 63 bytes
    7e 89 13 c1 30 37 02 01 00 04 06 70 75 62 6c 69 63 a2 2a 02 01 00 02 01 00 02 01 00 30 1f 30 1d 06 0d 2b 06 01 04 01 89 36 04 02 03 06 03 00 04 0c ff 02 03 00 01 25 88 0a 55 32 36 fd e7 7e

    Linux tocem04 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT
    2010 x86_64 x86_64 x86_64 GNU/Linux

    java version "1.6.0_17"
    Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
    Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

    Jar version = RXTX-2.2
    native lib Version = RXTX-2.2pre2

    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    HERE is a piece of code that is doing communication

    protected byte[] receive(
                int timeout, int maxBytes)
                throws ReceiveFailedException {
             boolean debug = log.isDebugEnabled() ;
             boolean trace = log.isTraceEnabled();
            InputStream in = null;
            if (this.isClosed())
                throw new ReceiveFailedException("Port '"
                        + this.getConnectionName() + "' has already been closed");
            byte[] retBuffer = new byte[0];
            SerialPort tmpSerialPort = this.getSerialPort();
            tmpSerialPort.setRTS(true);
            byte[] recvBuffer = new byte[maxBytes];
            String portName = tmpSerialPort.getName();
            BufferedInputStream bis = null;
            try {
             in = tmpSerialPort.getInputStream();
                bis = new BufferedInputStream(in);

                long startRecv = System.currentTimeMillis() ;
                long now = startRecv;
                int numRead = 0;
                int totalBytesRead = 0;

                // keep reading from the input stream unitl maxbytes are recieved or 
                // timout (maxRead Duration) is reached
                while (((now - startRecv) < timeout)
                        && (totalBytesRead < maxBytes)) {
                    numRead = bis.read(recvBuffer, totalBytesRead, bis.available());
                    if (numRead > 0) {
                        totalBytesRead += numRead;
                    }
                    now = System.currentTimeMillis() ;
                    // HDLC packet will always end with 0x7e. It will always be escaped in the data string.
                    if (totalBytesRead > 1 && recvBuffer[totalBytesRead-1] == 0x7e) {
                     break;
                    }
                }
                tmpSerialPort.setRTS(false);
                if (debug)
                        log.debug("["
                                                    + tmpSerialPort.getName()
                                                    + "] : Received " + totalBytesRead + " bytes.");
                //Copy what we have to the return buffer
                if (trace)
                                    log.trace("Raw Data [ "+portName +" ]:::"+ByteUtil.toHexString(retBuffer)+" : Received " + totalBytesRead + " bytes.");

                retBuffer = new byte[totalBytesRead];
                System.arraycopy(recvBuffer, 0, retBuffer, 0, totalBytesRead);

            } catch (Exception e) {
                String errMsg = "Port '" + portName
                        + "': Failure while reading data - " + e.toString();
                if (debug)
                    log.debug(errMsg);
                throw new ReceiveFailedException(errMsg);
            } finally{
             if (bis!=null)
                                    try {
                                            bis.close();
                                    } catch (IOException e) {
                                            
                                    }
            }
            // update timestamp
            setLastTimeReceived(System.currentTimeMillis());

            return retBuffer;
        }



----------------------------------------------------------------------------


    _______________________________________________
    Rxtx mailing list
    Rxtx at qbang.org
    http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1b3bb49d/attachment-0077.htm>

From Wei.Shen at Honeywell.com  Fri Dec  3 16:22:09 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Fri, 3 Dec 2010 18:22:09 -0500
Subject: [Rxtx]  rxtx how to recover from a disconnect
In-Reply-To: <952726.30532.qm@web63102.mail.re1.yahoo.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101203/1d5329bd/attachment-0077.htm>

From pplegrub at yahoo.co.uk  Sun Dec  5 12:11:06 2010
From: pplegrub at yahoo.co.uk (Rob Ferguson)
Date: Sun, 5 Dec 2010 19:11:06 +0000 (GMT)
Subject: [Rxtx] Parity errors - 0x00 bytes
Message-ID: <39875.88192.qm@web27805.mail.ukl.yahoo.com>

Hello All,

I would appreciate if somebody could clarify some points for me based on the details below -

OS: Ubuntu 10.10
IDE: Netbeans 6.9.1
RxTxComm: 2.1-7r2
Target device: Custom micro-controller using a 9-bit protocol.

Protocol: 
Target device transmit requests --> 1st Byte with MARK parity and all other bytes with SPACE parity. 
Target device receives response --> All bytes with SPACE parity. 

Questions:
1. Is it possible to switch between MARK/SPACE parity when transmitting/receiving with RxTxComm and are there examples available ?

2. When RxTxComm is configured with PARITY_MARK or PARITY_SPACE, only the data bytes that have correct parity are correct, all other bytes are changed into 0x00 - is there a way in which this functionality can be disabled?

3. Can a port be configured with a specific parity but parity errors can be ignored (I know this is possible when configuring an port from C in Linux).

Thank you in advance
Rob




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101205/5c19f995/attachment-0075.htm>

From Wei.Shen at Honeywell.com  Mon Dec  6 08:25:19 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 10:25:19 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>

Hi,

 

Any hint for this issue?

 

Wei Shen 

 

________________________________

From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 3, 2010 4:22 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx how to recover from a disconnect

 

Hi all,

 

I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is
when a USB-serial connection is lost due to electrical magnetic shock; I
can not recover from it.  I can not close the port since the connection
is lost already. Then the next retry shows the port is in use; I can not
open the port anymore. I have to unplug and plug back the USB cable in
order to recover it.  Is there a way I can automatically recover from
the connection lost?  Thanks in advance. 

 

 

Wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20101206/90b1bd9d/attachment-0074.htm>

From george.dma at gmail.com  Mon Dec  6 08:35:38 2010
From: george.dma at gmail.com (George H)
Date: Mon, 6 Dec 2010 17:35:38 +0200
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTimswiX-S-eJyk_LaAXtJO4WV-eHYkmxh9dsN=TW@mail.gmail.com>

Hi,

I have sort of had this problem before but with a serial printer. My
only way to recover was to unplug and re-plug like you said.

I think the solution lies within the operating system. When you
un-plug and re-plug I assume the OS re-scans the USB ports and assigns
a name or block device for that port, to which rxtx can later be able
to connect to. I guess you'd need to figure out how to get windows to
rescan the usb ports as if you re-plugged the thing.

It's a start. Hope it helps.
--
George H
george.dma at gmail.com



On Mon, Dec 6, 2010 at 5:25 PM, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Hi,
>
>
>
> Any hint for this issue?
>
>
>
> Wei Shen
>
>
>
> ________________________________
>
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Shen, Wei (AB21)
> Sent: December 3, 2010 4:22 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] rxtx how to recover from a disconnect
>
>
>
> Hi all,
>
>
>
> I am using rxtx-2.1-7r2 on windows machine. The issue I am facing is when a
> USB-serial connection is lost due to electrical magnetic shock; I can not
> recover from it. ?I can not close the port since the connection is lost
> already. Then the next retry shows the port is in use; I can not open the
> port anymore. I have to unplug and plug back the USB cable in order to
> recover it.? Is there a way I can automatically recover from the connection
> lost? ?Thanks in advance.
>
>
>
>
>
> Wei
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>


From msemtd at googlemail.com  Mon Dec  6 09:35:18 2010
From: msemtd at googlemail.com (Michael Erskine)
Date: Mon, 6 Dec 2010 16:35:18 +0000
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com>
	<952726.30532.qm@web63102.mail.re1.yahoo.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com>
	<83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
Message-ID: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com> wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine


From Wei.Shen at Honeywell.com  Mon Dec  6 18:02:11 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:02:11 -0500
Subject: [Rxtx] rxtx how to recover from a disconnect
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5473@DE08EV1001.global.ds.honeywell.com>

Hi Michael,

Thanks for your reply. I did not close the port from an event handler. I
do not know if the port was closed successfully or not. However, I got a
port in use exception when next time I try to open it. 

The following is the code. When the connection is lost, it thrown
IOException. The catch block then closes the port. Then it tried to
reopen the same port in order to recover from the connection failure.
This is where I got the port in use exception.  I really appreciate it
if you can give me any suggestion. Or can you share your recovery
mechanism? Thanks.


"
try {
				sendMessage(destination, payLoad);
				receivedMessage = receiveMessage();
				return receivedMessage;
			} catch (Exception e) {
				e.printStackTrace();
				log.error(e);
				link.getPort().close();
				System.err.println("port
closed:"+link.getPortName());
				
					String portName =
link.getPortName();
	
CommPortIdentifier.getPortIdentifier(
	
portName).open("Comm", 50);
"

Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Michael Erskine
Sent: December 6, 2010 9:35 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] rxtx how to recover from a disconnect

On 6 December 2010 15:25, Shen, Wei (AB21) <Wei.Shen at honeywell.com>
wrote:
> Any hint for this issue?
> I can not close the port since the connection is lost
> already.

Why can you not close the port? Isn't losing the connection exactly
like pulling the USB adapter? My software can recover from such a
failure well enough.

Remember folks: don't try to close the port from an event handler!

Regards,
Michael Erskine
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Mon Dec  6 18:08:34 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Mon, 6 Dec 2010 20:08:34 -0500
Subject: [Rxtx]  rxtx hang on RIM virtual serial port
In-Reply-To: <AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com>
	<AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen


From mariusz.dec at gmail.com  Mon Dec  6 23:00:14 2010
From: mariusz.dec at gmail.com (M.Dec-GM)
Date: Tue, 7 Dec 2010 07:00:14 +0100
Subject: [Rxtx] rxtx hang on RIM virtual serial port
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>

Hi,
Me and friends here have several times discussed about closing port in RXTX 
and recovering connection.
I have published several times example which shows way to recovery 
connection.
It works with 2.2 pre and have helped several times.
Look for this and try, especially in simple back-loop connection.
It should show proper (or not) work of the drivers.
Generally - change RXTX to 2.2 pre.
Regards
Mariusz


----- Original Message ----- 
From: "Shen, Wei (AB21)" <Wei.Shen at honeywell.com>
To: <rxtx at qbang.org>
Sent: Tuesday, December 07, 2010 2:08 AM
Subject: [Rxtx] rxtx hang on RIM virtual serial port


> Hi all,
>
> I recently installed the RIM USB and modern driver for the BlackBerry
> 9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
> talk to the RIM virtual port. Has anyone encountered this before? What
> is the solution for it? Thanks.
>
>
> Wei Shen
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



From Wei.Shen at Honeywell.com  Tue Dec  7 08:23:27 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:23:27 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF48E78C01CA5268@DE08EV1001.global.ds.honeywell.com><AANLkTi=QwgeDERPyg4xB2xkjBAeoH1sw89ejeztxnk_d@mail.gmail.com>
	<83B3B1411349194D9D05821CEF48E78C01CF5475@DE08EV1001.global.ds.honeywell.com>
Message-ID: <83B3B1411349194D9D05821CEF48E78C01CF5685@DE08EV1001.global.ds.honeywell.com>

Hi,

Anyone has encountered this before? Is there a solution for it? This is
a different issue from my previous posting. Please help. Thanks.


Wei Shen

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Shen, Wei (AB21)
Sent: December 6, 2010 6:09 PM
To: rxtx at qbang.org
Subject: [Rxtx] rxtx hang on RIM virtual serial port

Hi all,

I recently installed the RIM USB and modern driver for the BlackBerry
9000 Model on Windows XP SP3 32 bit. I found RXTX hung when it tried to
talk to the RIM virtual port. Has anyone encountered this before? What
is the solution for it? Thanks.


Wei Shen
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx


From Wei.Shen at Honeywell.com  Tue Dec  7 08:24:23 2010
From: Wei.Shen at Honeywell.com (Shen, Wei (AB21))
Date: Tue, 7 Dec 2010 10:24:23 -0500
Subject: [Rxtx] rxtx hang on RIM virtual serial port
In-Reply-To: <74A73AEF87F04CCC8253D7FDE4EA7A35@mdam3>
References: <AANLkTikwEsopU4EwjXsgY3MH4NiH6_APuMsX1RCSWJyo@mail.gmail.com><952726.30532.qm@web63102.mail.re1.yahoo.com><83B3B1411349194D9D05821CEF48E78C01CA5025@DE08EV1001.global.ds.honeywell.com><83B3B1411349194D9D05821CEF